What does this PR do?

This PR restructures the code in app/caches.py to implement a bridge pattern by separating the cache interface from its implementation, so that either can be varied separately without changing the client (location service) code. To do this, I created a new interface (abstract base class) called Caches in the caches.py file, with definitions for abstract methods to get, check, and load the cache, as well as a property which stores the instantiation of the cache. Each of these method and property definitions don't do anything in the abstract base class, but simply raise NotImplementedError.

Then, I created two concrete implementations of the interface through the RedisCache and SimpleMemoryCache classes. Each implement the abstract methods defined in the base class, but use a redis-based cache and simple memory cache, respectively. I also needed to change some of the code in app/data/__init__.py to read the project settings and instantiate the proper cache to be used by each of the location services, as well as altered the location services themselves to use the Caches abstract base class in their cache operations. By doing things in this way, any cache implementation can be passed into any of the location services, and this can even be changed dynamically at runtime.

Why make these changes?

Since this part of the codebase contained the pattern of having the location services, which were implicitly combined with some cache variation, it made sense to de-couple the two via the bridge pattern. In this example of the pattern, the location services serve as the abstraction/refined abstractions, while the Caches abstract base class is the implementation, with the actual variations of the cache (RedisCache and SimpleMemoryCache) being the concrete implementations.

Doing this makes it possible to use any cache variation with any of the location services, without the need for individual subclasses for all the combinations of cache and location service. Using a bridge pattern here also makes it possible to introduce new location services and new cache variations independently from each other, since our code now only works with high-level abstractions. This change also breaks down the somewhat complex and monolithic app/caches.py file, and separates the code that decides on the cache to use from the actual implementation of the cache, thereby making the code more readable.